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METHODOLOGY FRAMEWORK AND DELIVERY VEHICLE 
COPYRIGHT NOTICE 

[0001] A portion of the disclosure of this patent document contains material 
which is subject to copyright protection. The copyright owner has no objection to 
5 the facsimile reproduction by anyone of the patent document or the patent 

disclosure, as it appears in the Patent and Trademark Office patent file or records, 
but otherwise reserves all copyright rights whatsoever. The following notice 
applies to any software and data as described below and in the drawings hereto: 
Copyright © 2003, Accenture, All Rights Reserved. 

10 BACKGROUND 

[0002] L Technical Field 

[0003] The present invention relates generally to an improved method of 
organizing and presenting complex, detailed information stored in electronic form. 
The invention may find particular use in organizations that have a need to 
15 document repeatable processes to reflect its work. Typically, such organizations 

need to define processes that address a variety of related work domains, such as 
methodologies, and a desire to pubhsh this information on a corporate intranet or 
the Internet. 

[0004] 2. Background Information 

20 [0005] A methodology is a collection of information that explains how to plan, 

mobilize and/or execute a certain type of work. In other words, a methodology is 
a specific way of performing a multi-stage operation that implies precise 
deliverables and/or outcomes at the end of each stage. Deliverables are 
measurable results or outputs of a process. Thus, a methodology defines types of 

25 work processes in terms of measurable results. A well-defined methodology 
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generally defines a business organization's best practices for accomplishing a 
given task and incorporates that organization's terminology. In this way, 
employees are able to refer to and integrate these best practices into their day-to- 
day performance of responsibilities. In order to take full advantage of this wealth 
of knowledge, methodologies must be accessible to various levels of employees 
throughout the organization. Publishing methodologies on an organization's 
intranet or securely on the Intemet makes the methodologies instantly accessible 
to potentially any authorized individual throughout the world. 
[0006] Three technical problems are generally encountered when defining and 
using a methodology across an organization. First, finding the appropriate content 
in a methodology using conventional browser interfaces is often difficult. 
Typically, methodologies are customized for specific business domains using 
interfaces and object labels that vary from one domain to another. For employees 
switching work roles from one domain to another or one project to another, not 
being familiar with the different interfaces and organization of information within 
a methodology makes it hard to locate the specific information that supports a 
given context. In organizations where this information is made accessible on the 
Intemet, poorly designed interfaces result in an increased number of data files, or 
documents, consuming large amounts of storage space. 

[0007] Second, traditional organizational models for accessing and displaying 
methodologies are inflexible. Typically, a methodology will be defined across 
multiple levels of hierarchically arranged data. There may be as many as six or 
more levels of detail hierarchically arranged in conventional methodologies. A 
typical user will need to drill through these levels to obtain the relevant 
information. The information at a given level may not be associated with the 
needs of users at a given role level, requiring greater navigation up and down 
through the hierarchy to locate pertinent information. As the information is 
published on the Intemet, more levels of abstraction directly translates into 
increased network traffic and strained network resources. 
[0008] Third, the data representative of highly integrated methodologies are 
difficult to maintain as a result of the high volume of explicit and implied 
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relationships that exist among methodology data objects. If the data is spread over 
multiple levels of abstraction, the complexity involved in maintaining this 
information increases. Additionally, storage space is required to maintain each 
level. Thus, minimizing the levels of abstraction reduces the amount of data being 
5 stored, and keeping the data to a minimal level curtails the complexities involved 

in updating and supplementing an organization's methodology collections. 
[0009] The present invention solves these technical problems by providing a 
new paradigm for storing, maintaining, delivering and transforming the data 
representative of the methodology. 

10 BRIEF SUMMARY 

[0010] In one embodiment, a hierarchical framework for a library of software 
process management methodologies includes at a first level of hierarchy, a 
collection of activities that describe the process, wherein each activity requires the 
use of a unique skill set domain. At a second level of hierarchy, the framework 

15 includes a collection of tasks that describe the activity. At a third level of 

hierarchy, the framework includes a collection of steps that describe the task. For 
each methodology, a portion of the activities are categorized across a set of 
taxonomies common to a plurality of methodologies contained in the library such 
that the portion of activities is reusable for the plurality of methodologies. 

20 [0011] In another embodiment, a method is provided for mapping a knowledge 

base into a hierarchical framework to facilitate reusability of task objects between 
related work domains, wherein the objects contain descriptions of tasks for 
executing an information technology methodology. The method includes defining 
a set of taxonomies comprising members of a universe of activity objects for a 

25 methodology; organizing a set of task objects of singular granularity into object 

groups having in common a relation to one member of the taxonomy; and 
publishing onto an application server for access by a user through an electronic 
display a plurality of documents having a hierarchical linkage, wherein a highest 
level document displays the set of taxonomies with links to a set of second level 

30 documents, each second level document representing an activity object 
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instantiation of a single member of the taxonomy, the second level document 
having links to a group of third-level documents, each third level document 
representing a task object instantiation of a single task object of singular 
granularity; wherein each methodology is mapped to a selection of a set of 
5 taxonomies, whereby an instantiation of an activity object from one methodology 

may be reused for another methodology. 

[0012] In yet another embodiment, a method is provided for providing access 
to information and deliverable samples for executing an information technology 
methodology. The method comprises (i) displaying a first pictorial display of a 

10 planning chart comprising a plurality of stages and workstreams arranged in an 

orthogonal relationship; (ii) providing, embedded in the first pictorial display, a 
first link/code at an intersection of a stage and a workstream, the first link/code 
providing access to a second pictorial display; (iii) executing the first code to 
display a second pictorial display consisting of information contextually related to 

15 the stage and the workstream and comprising a plurality of objects having a 

parent-child relationship with the intersection; (iv) providing, embedded in the 
second pictorial display, a second link/code associated with each object, the object 
code providing access to a third pictorial display; and (v) executing the code to 
display the third pictorial display representative of a process for providing a single 

20 principle deliverable. 

[0013] These and other embodiments and aspects of the invention are 
described with reference to the noted Figures and the below detailed description of 
the preferred embodiments. 

BRIEF DESCRIPTION OF THE DRAWINGS 
25 [0014] FIG. 1 is a representation of the integration of the top level planning 

charts for a development and an operations framework in accordance with the 
present invention; 

[0015] FIG. 2 is a schematic of the relationship between the primary and 
supplemental content of a methodology in accordance with the present invention; 
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[0016] FIG. 3 is a schematic of a relational content model of a framework in 
accordance with the present invention; 

[0017] FIG. 4 is a diagram representative of the development architecture and 
the data flow of one embodiment of a methodology publishing environment for a 
5 methodology delivery infrastructure in accordance with the present invention; 

[0018] FIG. 5 is a representative screen shot of a top-level planning chart view 
for presenting a development methodology in accordance with the present 
invention; 

[0019] FIG. 6 is a representative screen shot of an activity view for presenting 
10 a development methodology in accordance with the embodiment of FIG. 1; 

[0020] FIG. 7 is a representative screen shot of a task view for presenting a 
development methodology in accordance with the embodiment of FIG. 1; 
[0021] FIG. 8 is a representative screen shot of a top-level plarming chart for 
presenting an operations management methodology in accordance with the present 
15 invention; 

[0022] FIG. 9 is a representative screen shot of an activity view for presenting 
an operations management methodology in accordance with the present invention; 
and 

[0023] FIG. 10 is a representative screen shot of a task view for presenting an 
20 operations management methodology in accordance with the present invention. 

DETAILED DESCRIPTION OF THE DRAWE^GS AND THE 
PRESENTLY PREFERRED EMBODIMENTS 

[0024] The embodiments discussed in this application relate to two types of 
methodologies: development methodologies and operations methodologies. 
25 Referring to FIG. 1, a representative top level planning chart is depicted showing 

the overview of an application development methodology 110 transitioning into an 

application management operations methodology 150. 

[0025] Development methodologies are collections of information that explain 
how to plan, mobilize and/or execute the development of a product, for example, 
30 application development. Operations methodologies are collections of 
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information that explain how to plan, mobilize and/or execute business operations, 
for example, application management. It should be apparent to one of ordinary 
skill in the art that the principles discussed in relation to these embodiments are 
equally applicable to other types of methodologies without departing from the 
spirit and scope of the invention as claimed below. 

[0026] In one embodiment, developing an application comprises a variety of 
processes that occur in a linear model, with set transition points that allow for 
multiple team members to transition seamlessly from one process to another, 
regardless of which team member is performing which process. On the other 
hand, operations methodologies are typically non-linear, and have no set transition 
points to dictate when to end one process and begin another. Rather, there exists a 
fluid relationship between areas of work that must be continually done over the 
life of an organization. 

[0027] While these two types of methodologies differ in many respects from 
each other, in some respects they both have similar guiding principles. As such, 
by recognizing these principles, both methodologies may be defined in a simple, 
consistent, and flexible way. Additionally, any approach for defining these 
methodologies must be adaptable to many types of processes and areas of work. 
In one embodiment, these goals are accomplished by organizing a methodology 
into processes based on the skill sets required to complete the processes. Using 
this approach, these different types of methodologies can be defined with a data 
model common to all or most of the methodologies. 

[0028] In addition to utilizing a common underlying data model, utilizing a 
similar interface to provide access to the methodologies also fiirther the goals of 
simplicity, consistency, and flexibility. The common data model recognizes that 
the methodologies may be defined by a set of taxonomies that includes the 
members of the universe of activities included in the methodologies. For 
development methodologies that include a logical linear sequence of processes, 
the methodologies may be defined by two sets of taxonomies, a linear time-based 
taxonomy and a skill set-based taxonomy arranging the sub-processes by the skill 
sets required to perform the processes. In this latter approach, the activities are 
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then defined by the intersection of one member of the linear time-based taxonomy 
with one member of the skill set-based taxonomy. Defining, organizing and 
categorizing the processes that make up the methodologies into these common 
activities allows the defined process sub-sets to be reused for defining or creating 
additional methodologies. 

[0029] In one embodiment, the methodologies are presented across three levels 
of abstraction. Initially, a top-level planning chart is presented as an overview of 
the entire methodology. FIG. 1 provides exemplary top-level planning charts for a 
development methodology 110 and an operations methodology 150 for one 
embodiment of the present invention. 

[0030] The Development Methodology Framework (DMF) 200 is structured as 
a matrix of stages 112 and workstreams 114. The vertical bars are the stages 112 
of work within a project. In one embodiment, the intersections of the stages 1 12 
and the workstreams 1 14 are embedded with code segments providing links to 
documents, described in more detail below. For example, the intersection 1 16 of 
the Design stage 118 and the AppUcation workstream 120 links to another detailed 
display representing a discrete activity to be performed for this methodology. In 
this embodiment, there are six stages for a DMF 110 methodology. While these 
stages will be explained in regards to an application development methodology, it 
should be apparent to one of ordinary skill in the art they are equally applicable to 
any type of methodology using a linear model. Moreover, the stage definitions are 
exemplary and should not be constmed as limiting in any way. 
[0031] In the first stage in FIG. 1 , plan 122, a blueprint for the project is 
defined and the project is organized. In other words, the business goals, scope, 
and high-level requirements of the project are determined. In the second stage, 
analyze 124, project requirements are gathered, identified, analyzed, and managed, 
for example, evaluating packaged software and technology infrastructure 
components. In the third stage, design 118, the applications, technical 
architecture, technical infrastructure, and application training materials are 
designed. In the fourth stage, build 126, the applications, technical architecture, 
technical infrastructure, and application training materials are developed. In the 
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fifth stage, test 128, the components built by all workstreams are tested and the 
solution as a whole is validated with test users. In the final stage, deploy 130, the 
application, technical architecture, technical infrastructure, and training materials 
are rolled out to the organization. 
5 [0032] The horizontal bars 114 of FIG. 1 represent workstreams defined as a 

domain or area of work. Workstreams 1 14 group together processes usually 
performed by a team of people with related skill sets. The processes are organized 
into a set of nine workstreams 1 14 that are considered generally applicable to the 
universe of development methodologies. Five are shown in FIG. 1 , and are 

10 defined as follows: Project Management 132; Application 134; Technical 

Architecture 136; Training & Performance Support 138; and Service Introduction 
140. The remaining four workstreams that are part of the library of standard 
workstreams, which are not shown, are Business Process; Organization; Facilities 
& Equipment; and Content. These labels and their accompanying definitions are 

15 intended to be illustrative, and should not be considered limiting in any way. 

[0033] In addition to defining activities as groups of tasks that relate to 
performing work within a skill set or workstream related to a particular stage of 
the project, the methodology framework also provides transitions between 
activities and stages. A transition point represents an interface between two teams 

20 on a project. At a transition point, project deliverables (requirements, design 

documents, code, etc.) are transitioned from one team to another. The main 
purposes of the transition points are to ensure the quality of deliverables being 
transitioned and to foster effective communication between the "sending" and 
"receiving'* teams to reduce project risks. 

25 [0034] On the top level planning chart, a box 142 after a first activity, for 

example design application 116, may be embedded with a code segment 
representing a link to a detail display depicting information related to the process 
for transitioning between the activity of design application 116 and the next 
activity, build application. A summary display of the collective transition activity 

30 between one stage, for example design 118 and the next stage build 126, may also 



-9- 



Atty Docket No. 10022/350 



be embedded in the "T" labeled chevrons 144 at the bottom of the top level 
planning chart. 

[0035] It is not necessary to have transitions between each and every activity, 
or for every workstream. For example, because the planning stage represents a 
5 common starting point requiring input from all work skill sets, this stage is 

embedded with a single link to a more detailed display, which depicts all the 
activities for this stage with a single transition point that splits into the four 
multiple workstreams 1 14 of linear activities. Likewise, at the conclusion of the 
test stage, it is preferred that each workstream's activities conclude with separate 

10 transition points that merge into a common single stage of a coordinated 

deployment of the application. Accordingly it is preferred that the Deploy stage 
be embedded with a single link to a more detailed display depicting all the 
activities for this stage not separated by workstream or skill set. Accordingly, it is 
preferred that a single transition link 146 is also provided between the deployment 

15 stage 130 or end of the Application Development methodology and the 

Application Management methodology 150. 

[0036] As noted above, the Operations Management methodology represents 
the management of fluid non-linear activities to support the ongoing operations 
management of the deployed system. As such, the framework employed depicts a 

20 matrix of eight activities surrounding a single activity to indicate the supporting 

and core relationships between the activities. For example. Fig. 1 depicts the core 
activity to Provide Service: Application Management 152. The other eight 
supporting activities are organized to provide a common set of activities that 
universally support all core activities of different operations management 

25 methodologies. Thus, it is evident that the content from the supporting activities 

are reusable across many different operations management methodologies by 
swapping out the new core activity. 

[0037] As with the Development Methodology top level planning chart 1 10, 
the Application Management Planning chart has a code embedded in the box 
30 depicting each activity, with the code providing an active link to a detailed display 
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depicting the tasks required to perform the activity, as explained in more detail 
below. 

[0038] Before describing the data model supporting the development of the 
framework, it may be best to describe how the core objects of the methodology fit 
5 with in the larger picture of the primary and supplemental elements within and 

linked to the methodology. Referring now to Fig. 2, a schematic representing the 
methodology 200 is depicted. At its core, the metadata model noted in detail 
below is divided into three key types of content in the methodology: Processes 
202; Deliverables 204; and Roles 206. Processes 202 are defined as what a team 

10 member needs to do, and are preferably broken down hierarchically as activities, 

tasks and steps, as discussed in more detail below. Deliverables 204 are defined as 
what a team member needs to produce. Roles 206 are defined as job descriptions 
for a team member. These three content types all reference each other to form the 
foundation of the methodology, as shown in FIG. 2. Accordingly, the metadata 

15 model is designed to allow for flexible cross-referencing and linking between 

process objects that relate to associated roles and deliverables, and vice versa. 
Processes 202 require the skills of at least one role 206, and resuh in one or more 
deliverables 204. Various roles 206 perform processes 202 and create deUverables 
204. DeUverables 204 require the skills of at least one role 206. Therefore, the 

20 model should allow one to view from the perspective of a specific role, the 

associated processes that role is involved in and the associated deliverable that role 
creates or supports. A likewise perspective is also provided from a specific point 
in the process or from a specific deliverable. 

[0039] Three optional supplemental content types are also shown in FIG. 2. 

25 These supplemental content types provide additional information about the 

processes 202 and deliverables 204 for a team member performing a particular 
role 206. Job aids 208 provide a team member with information to assist the team 
member performing a role 206 to complete an element of the process 202. 
Checklists 210 provide a framework for a performer of a role 206 to create a 

30 deliverable 204. Finally, external resources 212, such as white papers or vendor 
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manuals, may provide infomiation about how the process 202 results in the 
deliverable 204. 

[0040] In one embodiment, there are two levels of documents in the core 
methodology framework that describes the process elements: Activities and Tasks. 
5 Activities are large units of work with a single major outcome. For example, the 

Design Application activity 116 results in the Application Design deliverables. 
Activities are composed of tasks. Tasks are smaller units of work that are 
performed by one individual or team to create a single primary outcome. Tasks, in 
tum, are described as a sequence or compilation of steps. 

1 0 [0041] A typical methodology may involve complex interactions among 

multiple teams; multiple releases; multiple people, processes, and technology 
elements; and multiple schedules. To address these complexities, the 
methodology data model has been designed to provide a presentation interface that 
supports personnel with different types of information needs, because different 

1 5 roles use methodologies in different ways. For most methodologies, there are two 

major types of roles: "Planners" and "Doers". These broad classifications provide 
a basic guideline for determining which information is most applicable to different 
types of personnel, based on the type of work they are responsible for. 
[0042] Individuals responsible for structuring, estimating, and managing work 

20 on a program or project represent the "planner" role. Planners* activities occur 

whenever there is a need to evaluate a potential course of action, create a work 
plan, or manage a team. Information at the activity level is organized specifically 
to meet the needs of "planners." Each activity may contain the following 
information types commonly used by "planners:" 

25 [0043] Planning charts that illustrate the relationships among the tasks of an 

activity. A planning chart can help "planners" gain an understanding of the 
overall structure and scope of work within an activity. 

[0044] Objectives describe the purpose and intended outcomes of the activity. 
Objectives may be used for initial guidance regarding the relevance of a task. 
30 [0045] As described above, deliverables are produced as a result of the work 

conducted in the activity. Planners can review the deliverables listed in this 
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section as they are planning the work to ensure that they understand the desired 
resuh of an activity. 

[0046] Roles define the responsibilities of a team member. This information is 
useful to a "planner" in staffing and balancing the workload of a project. 
5 [0047] Relationships between workstreams explain the dependencies of an 

activity or workstream on other activities, and in tum what other activities need 
from your activity. 

[0048] Summary-level statements and supporting narratives to help in 
managing, planning, and staffing the activity may also be provided. In one 
10 embodiment, these are called considerations. Considerations are used to document 

key issues, practical advice, and intangible factors related to the activity. This 
section can be helpful when considering how to structure the work, or how to 
manage work in progress. 

[0049] Job aids or other resources that are related to the activity are also 
15 helpful to a "planner." Job aids can be used to help orient the "planner" to the 

nature of the work conducted, when it can be considered complete, and how it is 
structured. 

[0050] As described above, one of the underpinnings for the methodology 
framework is to provide a three-tiered presentation layer specific to roles played in 

20 methodology process. "Doer" is a collective term for the personnel responsible 

for creating the business capability by executing the processes within the 
methodology. This is a collective term in that there are many different types of 
"doers." In one embodiment, "doers" can range from application designers, to test 
managers, to service management experts. 

25 [0051] The distinction between a "Doer" and a "Planner" exists in terms of 

roles or frames of reference rather than actual personnel. In reality, an individual 
may plan work and do work as appropriate, and hence can be considered both a 
"planner" and a "doer." The methodology uses the concept of a "doer" to identify 
the methodology information required to execute the methodology process and 

30 complete the required deliverables to the desired level of quality. 
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[0052] The task planning chart provides "doers" with an overview of the scope 
of work that must be performed at the task level, and preferably the entire scope. 
Task planning charts can help define relationships among related actions. Task 
planning charts are divided into steps, which illustrate how work should be 
5 conducted, and may also point out iteration conditions. Task planning charts do 

not necessarily differ between development and operations methodologies, as 
every business process is a series of steps at its lowest level. 
[0053] Typically, other information of importance to a "doer" will be provided 
to supplement a task planning chart. "Doers" consult this information to help 

1 0 them execute or do the work as these materials help them understand various 

aspects of that work. This information may include: 
[0054] Deliverables, which represent information that is generated and 
captured during the execution of a methodology process. Deliverable and work 
object samples may optionally be included, and represent templates that can be 

15 used to structure the details of the work contained within a task. Understanding 

the structure of this information is critical to completing the work successfully. 
[0055] Role information that define the responsibilities of a team member. 
This information is useful in understanding what expertise is needed to perform 
the work. 

20 [0056] Step descriptions that provide an explanation of each step in a task's 

planning chart. Step descriptions may provide the "doer" with additional detail for 
completing each step of the task. 

[0057] Job aids containing detailed information related to specific tasks within 
the methodology. Technique and guideline type job aids are particularly useful for 
25 "doers," as they include specific detailed explanations of how to conduct the work. 

[0058] Summary-level statements and supporting narratives. In one 
embodiment, these are called key considerations. Understanding the planning 
considerations and the advice they contain is just as important for personnel 
executing the work as it is for those personnel planning the work. 



30 
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[0059] Referring now to FIG. 3, a schematic of a relational content model for a 
library 302 of frameworks for several methodologies in accordance with the 
present invention is shown. In one embodiment, a methodology is defined as a 
collection of data objects, namely: methodology objects 304, activity objects 306, 
5 task objects 308, transition point objects 310, composite objects 312, deliverable 

objects 314, role objects 316, and supplemental objects 318. These objects are 
used to populate presentation templates, creating static documents that are made 
available to the end user, for example, on the Internet, such as described below 
with reference to the publishing environment depicted in FIG. 4. 
10 [0060] Preferably, relationships between the data objects are defined in 

relationship objects. The relationship objects are used to validate the information 
in the data objects and define links between the static documents populated with 
the data of the data objects. 

[0061] Referring again to FIG. 3, the methodology objects 304 are 
15 administrative objects used to organize the information that pertain to the 

particular methodology being defined. As will be described in more detail below, 
each activity object 306 used to define a particular methodology must belong to a 
methodology object 304. 

[0062] Activity objects 306 define the processes necessary to produce the 
20 deliverables and outcomes for a specific workstream 1 14 during a specific stage 

1 12 of a development methodology, or for a single activity of an operations 
methodology. Task objects 308 define the individual actions required to complete 
the activity. Activity information is targeted to presentation to person performing 
a role 3 16 as a manager, and is divided among task objects 308. The data 
25 contained in an activity object 306 may include, for example, the name and ID 

information for the activity. A list of the principle objectives and outcomes for the 
activity, business considerations for planning, managing, staffing and successfully 
completing the activity, and estimating factors may also be defined in an activity 
object 306. 

30 [0063] The data contained in an activity object 306 may also include links to 

objects describing the inputs and outputs of the activity, which may be 
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deliverables or composites as discussed below. Preferably, the inputs and outputs 
are grouped by which deliverables are critical to the activity, also called primary 
inputs or outputs, and those which are useful but not needed, or secondary inputs 
or outputs. Optionally, the deliverable information may include a schematic of the 
5 deliverables for the activity, including their sequence and inter-relationships. Role 

information may also be contained in an activity object 306. 
[0064] Other information stored in the activity object 306 may include the 
identification of the methodology to which the activity belongs, a description of 
the dependencies between the activity and activities in other workstreams, 
10 workflow schematics, and administrative information, such as version numbers 

and the like. Workflow schematics show the tasks for the activity, and may 
include their sequence and inter-relationships. The activity object 306 may also 
include a list of and links to additional references both within the methodology 
and extemal to it. 

15 [0065] In one embodiment of a development methodology in accordance with 

the present invention, every activity object 306 must belong to a methodology 
object 304. Each activity object 306 has a parent-child relationship with at least 
one task object 308 and, with the exception of a few activity objects such as for 
project management, preferably with at least one transition point object 310. 

20 [0066] Operations activity objects contain the same information as a 

development activity object. Additionally, each operations activity object has a 
parent-child relationship with at least one task. However, an operations activity 
object does not have a parent-child relationship with a transition point object 310. 
This is a reflection of the non-linear processes defined in an operations 

25 methodology. 

[0067] As described above, tasks define the individual actions required to 
complete an activity. In one embodiment, this information is stored in task objects 
308. Typically, a task object 308 may include, for example, the name and ID 
information for the task. Each task object 308 also includes information defining 

30 the steps for completing the task. A list of the principle objectives and outcomes 

for the task, business considerations for planning, managing, staffing and 
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successfully completing the task, and estimating factors may also be defined in a 
task object 308. 

10068] The information contained in a task object 308 may include the inputs 
and outputs of the task, which may be deliverables or composites as discussed 
below. Preferably, the inputs and outputs are grouped by which deliverables are 
critical to the task, also called primary inputs or outputs, and those which are 
useful but not needed, or secondary inputs or outputs. Optionally, the deliverable 
information may include a schematic of the deliverables for the task, including 
their sequence and inter-relationships. Altematively, the task object 308 may 
contain links to the composite 312 and deliverable 314 objects containing that 
information. Role information or links to relevant role objects 316 may also be 
contained in a task object 308. 

[0069] Other information stored in a task object 308 may include the 
methodology to which the task belongs, workflow schematics, and administrative 
information, such as version numbers and the like. Workflow schematics show 
the process steps for the task, and may include their sequence and inter- 
relationships. The task object 308 may also include a list of and link to additional 
references both within the methodology and external to it. 
[0070] Each task object 308 is a child of an activity object 306. Additionally, 
as noted above, relationships may be established between task objects 308 and 
composite objects 312, deliverable objects 314, role objects 316 and supplemental 
objects 318. Similar relationships may be contained in activity objects 306. 
[0071] Because the tasks document displays do not link to lower level displays 
in the hierarchy and are typically defined as relating to a single outcome even 
though they may comprise multiple steps, they are referred to as having a singular 
granularity. Also, task objects do not have a relationship as a parent to a child 
object. 

[0072] Transition points are analogous to a special kind of task dedicated to 
transitioning already validated composite or deliverables to the next team 
responsible for continuing the project. For example, Transition Application 
Design 142 (see FIG.l) provides a user with information on what the design team 
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needs to transition to the build team, and what the critical outcomes should be. In 
other words, a transition point represents an interface between two teams on a 
project. At a transition point, you transition project deliverables (requirements, 
design documents, code, etc.) from one team to another. The main purposes of the 
5 transition points are to ensure the quality of deliverables being transitioned and 

foster effective communication between the "sending" and "receiving" teams. 
Transition points are particularly useful where development occurs over multiple 
sites. 

[0073] Transition point objects 310 define the information needed to transition 
10 a validated deliverable or composite from one team to another. In one 

embodiment, transition point objects 310 may include the name and ID 
information for the transition point. Each transition point object 310 also includes 
a description of how to perform the process steps of the transition point. A list of 
the principle objectives and outcomes for the transition point, business 
1 5 considerations for planning, managing, staffing and successfully completing the 

task, and estimating factors may also be defined in a transition point object 310. 
[0074] The information contained in a transition point object 310 may include 
the entry criteria and exit criteria of the transition point. Each transition point 
object 310 may also include a list of the deliverables that are to be transitioned 
20 during the transition point. Role information may also be contained in a task 

object 310. 

[0075] A composite is a group of related deliverables that are referenced as a 
single item. For example, composite A may include deliverables B, C, and D. 
Each composite A may contain zero, one, or many instances of each item B, C or 
25 D. Collectively, however, all instances of composite A serve one purpose in 

relation to the task or activity being performed. 

[0076] Composite information is defined in composite objects 312. The 
composite object 312 typically contains a name and ID for the object. Composite 

objects 312 may contain a description of the composite, including its purpose, a 
30 list of deliverables associated with the composite, and role information. In one 

embodiment, the composite objects 312 include information explaining who uses 
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the composite and for what purposes. The number of instances of the composite 
may also be stored in a composite object 312. The composite object 312 may 
define a list of the tasks that create the composite and which tasks use the 
composite. Other information, such as a list of job aids, checklists, reference 
5 materials and external resources may optionally be defined in a composite object 

312. 

[0077] As explained above, deliverables are measurable results or outputs of a 
process. Deliverable objects 314 contain definitions of the deliverable associated 
with a task object 308, The deliverable object 314 typically contains a name and 

10 ID for the object. Deliverable objects 3 1 4 may contain a description of the 

deliverable, including its purpose, a list of composites associated with the 
deliverable, if any, and role information. Optionally, deliverable objects 314 may 
contain links to templates and/or samples of the deliverable being defined. The 
templates and samples can be internal or external to the methodology. Preferably, 

15 any template associated with a deliverable object should include descriptions of 

the fields and sections of the template, as well as guidelines for completing the 
deliverable. Deliverable objects 314 may also include the number of instances of 
the deliverable, and information explaining who uses the composite and for what 
purposes. In one embodiment, the deliverable object 314 contains a list of the 

20 processes that create, update and/or use the deliverable, and links thereto. Other 

information, such as a list of job aids, checklists, reference materials and external 
resources may optionally be defined in a deliverable object 314, along with 
associated links. 

[0078] Roles are the skill sets needed to complete a task. A person on a team 
25 may have one or more roles on the project. Similarly, more than one person on a 

team may share a role. In one embodiment, there are two types of roles in the 
methodology. Responsible roles are the roles that are primarily responsible for 
completing a task or deliverable, while participating roles are the roles that assist 
in completing a task or deliverable by reviewing the work or providing the 
30 expertise. 
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[0079] Roles are defined in role objects 316. Typically, a role object will 
include a name and/or ID. In one embodiment, role objects 316 include a list of 
the responsibilities for the entire methodology of the role being defined, and a list 
of the abilities expected for the role. As explained above, task objects 308 may 
include role information and/or links thereto. Inversely, role objects 316 may 
include a list of the tasks associated with the role and/or links thereto. In one 
embodiment, this list is divided into the tasks wherein the role is a responsible role 
and tasks wherein the role is a participating role. Similarly, role objects 316 may 
include a list of and links to related deliverables (or composites). This list may 
also be divided into deliverables (or composites) the role is responsible for, and 
those deliverables that the role is participating in. Other information, such as a list 
of job aids, checklists, reference materials and extemal resources may optionally 
be defined in a role object 316. 

[0080] Supplemental objects 318 provide links to information regarding 
additional assistance for users in the form of job aids, checklists, reference 
materials, and extemal resources. Job aids provide additional guidance for 
completing a task or deliverable. In one embodiment, there are three types of job 
aids. Overview job aids provide a description of key concepts and background 
information. Guideline job aids provide specific information on issues, 
considerations, and approaches for completing a task. Technique job aids provide 
specific information on a specific approach or method of achieving a result. 
[0081] Checklists provide tools for quick quality checks at key points in the 
process. In one embodiment, each checklist comes with an attachment, allowing a 
user to easily download a copy of a checklist, customize it as necessary for a 
project, complete it, and store it with project deliverables. 
[0082] Reference materials provide contextual information and 
recommendations for using a particular methodology. For example, these 
reference materials can be used to help develop presentations for customers or 
training for project team members. In one embodiment, reference materials may 
include schematics overview for an entire workstream, or information detailing the 
dependencies between workstreams. Extemal references are links to additional 
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resources outside this methodology, including references to internal databases, 
web sites, book descriptions, and other methodologies. 
[0083] In the relational data model, the diamond icon 320 represents the 
"contains" relationship that is also a parent-child relationship between objects. 
The icon 320 represents the hierarchical relationship between objects in the 
framework. As may be recognized in the data model, the simplified hierarchical 
structure provides many technical advantages to the present invention over prior 
complex data models representing methodologies having six or more levels of 
hierarchy. This data model provides significant advantage in the technical 
development and publishing environment where the relational data base model and 
content of the methodology are maintained and published as static documents 
accessible, for example, though a web browser on a corporate intranet. 
[0084] Referring now to FIG. 4, the architecture for a development and 
publishing environment 400 of a methodology delivery infrastructure is shown. 
This architecture is more fully disclosed in commonly-owned, co-pending U.S. 
patent application No. 10/367,618, filed February 14, 2003, which is incorporated 
by reference herein. 

[0085] In one embodiment, a development environment 400 is provided for 
creating static web pages representative of a metadata model created for defining a 
methodology. As stated earlier, a methodology is a collection of information that 
explains how to plan, mobilize and execute a certain type of work. Defining a 
methodology typically requires each type of work to be decomposed into 
elements. In one embodiment, elements are defined as objects. As discussed 
above, objects can have various types. In the development architecture 400 of 
FIG. 4, a plurality of content files 402 are provided. Each content file 402 is 
representative of an object/element of the particular methodology being defined. 
Additionally, the content files 402 are representative of a particular instance of 
each type of work. Each content file 402 defines an object containing an object 
type at least one object property and at least one explicit relationship. Each object 
is representative of a particular instance of the element of the type of work being 
defined in the current methodology. The object properties define variables 
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associated with an object, while the explicit relationships define links between 
particular objects. It should be noted that the explicit relationships defined in the 
content files 402 should not be confused with the explicit relationship definitions 
discussed below. 

[0086] In addition to the content files 402, a plurality of rule files 404 are also 
provided. The rule files 404 define relationships generally. Relationships are 
defined by properties and explicit relationship definitions. The relationship 
properties define variables associated with the relationship being defined. The 
explicit relationship definitions can define how object types interact with one 
another generally. In one embodiment, these interactions are defined in terms of 
actions, or relationship operations, that are to be performed when certain 
conditions are satisfied. The conditions can be based on the properties associated 
with the relationship being defined, or can incorporate static variables, also known 
as constants. A variety of conditions are contemplated by the present invention. 
For example, one condition may be satisfied if two distinct object types are 
explicitly defined in the content files 402 to have a particular relationship. 
Additionally, actions can be dependent on multiple explicit relationships defined 
in the content files 402 or prefaced on certain property values. Referring also to 
FIG. 4, in one embodiment, the rule files 404 are provided within a hierarchical 
framework described in more detail below. Preferably, the content files 402 and 
rule files 404 are formatted in extensible markup language (XML). 
[0087] Because of the common taxonomies used to define the activities and 
hence the tasks comprising the activities, the content files 402 and rule files from 
one methodology already created may be copied and reused for new 
methodologies being created. Preferably, the content of complete workstreams of 
activity and task objects may be copied and reused with little or no modification. 
Nonetheless, relationships with other new content may need to be defined to 
integrate the reused content into the new methodology. 
[0088] Once all the content files 402 and rule files 404 are defined for a 
particular methodology, the architecture 400 of the present invention validates the 
information in the content files 402 with the relationship definitions of the rule 
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files 404. In the embodiment of FIG. 4, a transfomiation/validation utility 406 is 
provided. The transfomiation/validation utility 406 reads the information in the 
content files 402 and verifies the information is proper based on the explicit rule 
definitions provided in the rule files 404. For example, assume a content file 402 
defines an object A of type B having an explicit relationship of relationship type C 
with object D. Further assume that object D is of a type E. The transformation/ 
validation utility 406 will read this information fi-om the content file 402. The 
validation utiHty 406 then determines if objects of type B can have a relationship 
of type C with an object of type E by verifying the relationships defined in the 
rules file 404. Once verified, the transformation/validation utility 406 generates a 
link between the two objects to reflect the explicit relationship defined by the 
content file 402. Object properties may also be verified. For example, if object 
type C is invalid, the object property classifying object B as a type C object is 
incorrect. Additionally, implicit relationships and links are also generated by the 
transformation/validation utility 406. For example, an implicit relationship fi-om 
object D to object B is also generated by the transformation/validation utility 406, 
as discussed below. It should be appreciated that more complex explicit 
relationships and implicit relationships are contemplated by the current invention. 
[0089] In one embodiment, the transformation/validation utility 106 represents 
the explicit and implicit relationships in the form of a Structured Query Language 
(SQL) command. As known in the art, SQL is a language used to interrogate and 
process data in a relational database. SQL commands can be used to interactively 
work with a database or can be embedded within a programming interface to a 
database. In one embodiment, the SQL commands are generated by the 
transformation/validation utility 406 and stored in the rule files 404. The 
transformation/validation utility 406 performs a validation/transformation on each 
object described in the content files 402. 

[0090] Once the validation and SQL generation process is completed, the 
transformation/validation utility 406 extracts the data contained in the content files 
and transforms the data into two components. First, a methodology inventory file 
408 is created, listing each object defined in the content files 402. Next, the object 
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properties, explicit relationships, implicit relationships and links are entered into a 
relational database 410. 

[0091] A publisher utility 412 is provided with an optional configuration file 
414 to create static Internet documents, in a known maimer. In the embodiment of 
5 FIG. 4, a plurality of presentation templates 416 are provided to define a format 

for the Internet documents. As known in the art, the publisher utility 412 is 
adapted to access the relational database 410 and populate various fields in the 
presentation templates 416 incorporating the various relationships reflected in the 
database. In this way, the present invention is able to ensure maximum 
10 accessibility to a particular methodology, while maintaining enough flexibility to 

quickly adapt to changes in the methodology's content. 

[0092] Referring also to FIG. 4, the publisher utility 412 creates static Intemet 
documents by populating fields in presentation templates 416 with data contained 
in a relational database 410. The publishing utility 412 writes individual files and 

15 organizes these files into a methodology development web site 418. The 

methodology development web site 418 is organized into five categories of 
document types. A collection of Active Server Pages (ASP) content files 420 are 
provided. This collection contains the content pages for describing methodologies 
through the multiple interfaces described below. These pages can describe 

20 processes, deliverables, job aids, roles, reference materials, entry/exit criteria, 

organizations, commit points, overviews, lists ordered by type, or other custom 
HTML pages. Any attachments or images embedded in the content pages 420 are 
organized into the attachments collection 422 or images collection 424, 
respectively. All documents used to define and implement the navigation structure 

25 defined below in reference to the multiple user interfaces are organized into a 

navigational fi-amework collection 426. Finally, the search collection 428 contains 
the documents and tools required to perform the search fimctions described below 
in reference to the multiple user interfaces. 

[0093] Optionally, the methodology development web site can be published 
30 using a standard publishing tool, such as Front Page Publisher provided by 

Microsoft Corporation of Redmond, Washington, to create the product test 430 
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and staging 432 web sites. As known in the art, product test 430 and staging 432 
web sites allow developers an opportunity to find errors in the pages and/or 
content of the documents. Once the testing and staging process is complete, the 
production version of methodology development web site 434 is published to the 
5 methods production repository (not shown). The methodologies production 

repository is associated with an application server to allow authorized users access 
to methodologies throughout the corporate intranets and the Intemet. 
[0094] One embodiment of the three-tiered hierarchical user interface for a 
development methodology is depicted in FIGS. 5-7. This embodiment depicts 

1 0 representative screen shots for a methodology entitled "Custom Development." 

The interface for the methodology is shown within a browser interface 500 
referred to as a "Methods Browser" 500 which is described in more detail in 
commonly-owned, co-pending U.S. patent appUcation No. 10/367,618, filed 
February 14, 2003, which is incorporated by reference herein. This interface 

15 provides drop down menus 502 to access pertinent detail information within the 

methodology. Also, this interface provides a hierarchical tree table of contents 
504, or a text search 506 to access the methodology content. The selected 
methodology content is displayed within the active browser window 508. 
[0095] FIG. 5 depicts the top level planning chart 510 of the methodology 

20 within the active window 508. This workstream chart is similar to the 

embodiment shown in FIG. 1, and like items are referenced with numerals having 
similar tens and ones digits preceded with a 500 series. The planning chart 510 
has embedded within it links or codes executable to call up a display of a 
document informational related to the subject to which the area where the links are 

25 embedded. 

[0096] For example, the intersection 5 1 6 of the Design stage 5 1 8 and the 
Application workstream 520 is embedded with a code that links to the Design 
Application Activity. The hierarchical relationship of this Activity with the 
Workstream and the underlying tasks is also depicted within the Table of Contents 

30 tree 504. Clicking on the intersection 516 calls up the display of the Design 

Application document 600 as shown in Fig. 6. 



-25- 



Atty Docket No. 10022/350 



[0097] The highest level of the development framework 5 10, or the top-level 
planning chart, is shown as a simple matrix. In the embodiment of FIG. 5, it is not 
meant to show accurate time dependencies between the different workstreams. A 
link is provided to another document that shows a graphical depiction of the 
workstream dependency view 546 of the same activities represented in the top 
level planning chart 510. For example, all three analyze activities (Analyze 
Application, Analyze Technical Architecture, and Analyze Training and 
Performance Support) do not happen simultaneously; each workstream has 
interrelated dependencies that require some activities to precede others. However, 
they are all initiated from the Plan activity. A view of the dependencies in a more 
accurate time scale may be viewed in other graphic images accessible through the 
framework interface, for example, by providing a reference material document. 
Similarly, the simplicity of the framework does not graphically depict the likely 
iterations that will take place within the project. Iteration planning is done as part 
of the Project Management 532 workstream, as known to one of ordinary skill in 
the art. 

[0098] The project management workstream 532 may include such processes 
as defining the project work effort and resources; managing the risks, issues, 
quality, scope, and finances for the project; creating and maintaining project 
standards; control project work; measuring progress; and reporting status. Project 
management is shown separately in FIGS. 1 and 5 because it spans the entire life 
cycle of the project, and has many of the same activities performed on an iterative 
nature. The application workstream 534 may include processes relating to 
the development of the systems required to support the solution. This may include 
the user interface, content, business logic, and data. The technical architecture 
workstream 536 contains processes relating to the development of the technical 
architecture required for deployment of the solution. These processes may include 
developing the execution, development environment, and operations environments 
for the project. The training and performance support workstream 538 may 
include those processes necessary to develop the educational, performance 
support, and communication materials needed to support the use of the solution. 
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The service introduction workstream 540 may include processes needed to 
validate the operability of the application while determining what the application 
management unit needs to do to be ready to support the application. 
[0099] In the preferred embodiment, clicking on the intersection 516 of 
"Design" and "Application" opens the Design Application activity document 600 
within the active window 508 of the Methods Browser 500. For illustrative 
purposes, an exemplary development activity document 600 is shown in FIG, 6 
separate from the browser interface. An activity planning chart 602 is provided. 
The planning chart 602 contains a plurality of tasks 604 graphically depicted as 
boxes on the chart. Each box has a link or code embedded within the box to link 
to the display for the document describing details of the selected task. In this case, 
the tasks have been divided into sub-workstreams 610, 612 and 614 based on the 
specialized skill sets required to perform the tasks. 

[00100] Additionally, a validation gateway 608 is depicted in the planning 
chart 602. Finally, a transition point 606 is shown in the planning chart. 
Preferably, colors are used to designate the roles associated with the activities of 
the planning chart 408. For example, a grey box 616 indicates tasks that involve 
members of this team but are the responsibility of another team. Plan for 
Deployment 616 leverages team members performing the role of apphcation 
designers, but is the responsibility of the Deployment team. 
[00101] Preferably, a link 618 is provided in this activity document with an 
alternate graphical image showing the deliverable flow. Similar narrative content 
is provided in the alternate document, except that instead of tasks 604 in the 
planning chart, the chart includes the deliverable provided by the activity. 
[00102] Other information may also be included in the activity document 
600, which has been edited to better fit on a single sheet, and thus does not show 
all the information associated with the document. This other information includes 
objectives 620, which provides a list of the principle objectives and outcomes for 
the activity. The inputs and outputs of the activity, which may be deliverables or 
composites, may also be included. Primary inputs 622 provide a list of the most 
important inputs to the activity. Optionally, a list of secondary inputs (not shown) 
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may also be provided. Similarly, primary deliverables 624 and secondary 
deliverables 626 information may be provided. Responsible role information 628 
may also be displayed for the activity. Information regarding the activity's 
relationships with other workstreams 630 may be provided. Optionally, planning, 
staffing, managing and additional considerations (not shown) may be incorporated 
into the document 600. The listed information may be active hypertext to provide 
links to documents containing more detailed information. Also, the references 
may comprise sub-components that may be shown by expanding the listing by 
clicking the expand icons 632. 

[00103] Finally, the activity document 600 may include links to 
supplemental information. In one embodiment, these are titled "See Also." The 
See Also section may provide links to the supplemental content external to the 
methodology content. As described above, this supplemental content includes job 
aids, checklists, related processes and reference materials. Optionally, links to 
external resources outside the corporate intranet may also be provided. 
[00104] Clicking on any of the tasks 604 on the activity planning chart 602 
opens a task document, the lowest process level document in the methodology. 
An exemplary task document 700 is shown in FIG. 5. For example, by clicking on 
the task box 634 labeled "Design Components" the corresponding task document 
700 is displayed within the active browser window 508. Within the task document 
700 a task planning chart 702 is provided. As described above, the task planning 
chart 702 contains a plurality of process steps depicted as boxes 704 through 712. 
Unlike the top level planning chart and the activity planning chart at the first and 
second levels of the framework hierarchy, the boxes depicting the steps are not 
linked to lower level documents. Rather, the details of each step are described at 
the bottom of the document under the title "Process Steps" 714. The individual 
descriptions of the steps can be viewed by clicking the expand icon 732 by each 
step label. 

[00105] Other information may also be included in the task document 700. 
Objectives 720 provide a list of the principle objectives and outcomes for the task. 
The inputs and outputs of the task, which may be deliverables or composites, may 
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also be included. Primary inputs 722 provide a list of the most important inputs to 
the activity. Optionally, a list of secondary inputs 723 may also be provided. 
Similarly, primary 724 and secondary 726 deliverable information may be 
provided. Responsible role information 728 may also be displayed for the activity. 
5 Optionally, participating role information 730 may also be provided in the task 

document 700. Optionally, key considerations 734 for the task may be displayed. 
[00106] Finally, the activity document 700 may include links to 
supplemental information. In one embodiment, these are a titled "See Also" 
section which may provide links to checklists and extemal resources may also be 
10 provided. Links to other types of extemal resources may also be incorporated into 

the task document. 

[00107] One embodiment of a three-tiered hierarchical user interface for an 
operations methodology is depicted in FIGS. 8-10. FIG. 8 shows one embodiment 
of an operations management top-level planning chart 810 structured as a grid of 

15 interrelated activities as shown. These activities include a single core activity 812 

and eight supporting activities. Preferably, the supporting activities are common 
to other Operations Management Methodologies. The planning chart 810 for 
"Application Management" is displayed within the active window 808 of the 
methods browser interface 800. The planning chart 810 comprises a core service 

20 activity - Provide Service 812, and eight common supporting activities: Human 

Resources 814, Unit Management 816, Finance & Reporting 818, Performance 
Measurement 820, Process & Quality Management 822, Service Management 824, 
Technology Enablement 826, and Facilities & Equipment 828. Provide 
Service 812 includes the tasks and deliverables needed to provide continuing 

25 support of an organization's portfolio of applications, including problem 

resolution, ongoing maintenance, and enhancements. This activity is the central 
focus of the operations management methodology. 

[00108] Human Resources 814 includes guidance for creating and sustaining 
an operating workforce that is appropriately skilled and enabled, adaptable to 
30 changing work environments, and satisfied with career and employment 



-29- 



Atty Docket No. 10022/350 



opportunities. Task level detail and deliverables are available in referenced Human 
Resources knowledge sources. 

[001091 Unit Management 816 includes the tasks and deliverables required 
for the operation of the unit, enabling the unit to meet the business objectives of 
the customer and the company. This includes overseeing contracts with the client 
and third party providers, setting policies and strategic direction, and taking 
appropriate management action where necessary. 

[00110] Finance and Reporting 818 includes guidance for executing 
financial operations and reporting for a unit. Task level detail and deliverables are 
available in referenced financial management knowledge stores. 
[00111] Performance Measurement 820 includes the tasks and deliverables 
needed to ensure that all of the functions of the unit have information about the 
unit's performance and can take appropriate management action to correct any 
identified shortcomings. 

[00112] Process and Quality Management 822 includes the tasks and 
deliverables needed to establish a quality management approach for the unit that 
meets the expectations of the imit's stakeholders, implement the processes and 
procedures necessary to carry out the unit's functions, and identify and implement 
improvement. 

[00113] Service Management 824 includes the tasks and deliverables needed 
to manage the service interfaces between the customer and the unit, enabling the 
unit to define, manage, measure, and meet the customer's service expectations and 
achieve the agreed-on service levels. 

[00114] Technology Enablement 826 includes the tasks and deliverables 
needed for the provisioning and maintenance of services such as voice and data 
communications, software and hardware, technology equipment inventory, and 
software licenses for the engagement. 

[00115] Facilities and Equipment 828 includes guidance for provisioning 

and maintaining the facilities and equipment for the unit, from buildings, desks, 
chairs, and lights, to air conditioning and office supplies. Task level detail and 
deliverables are available in referenced knowledge sources. 
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[00116] Embedded in the area of each box representing the activities is a 
code or link selectable to display the activity document that provides an activity 
planning chart and detailed information describing the activity. 
[00117] Clicking on any boxes representing the activities in the high level 
5 display 810 opens an operations activity document. For example, clicking on Unit 

Management 816 opens the Unit Management activity document 900, as shown in 
FIG. 9. 

[00118] Referring to FIG. 9, in a preferred embodiment for an operations 

activity document 900, an activity planning chart 902 is provided. The activity 
10 planning chart 902 gives a planner access to tasks 904 through 912. As in the 

development activity planning chart 602, tasks 904 through 912 are the series of 
actions, typically having a singular deliverable, required to complete the activity. 
Unlike the development activity planning chart 602, the operations activity 
planning chart has no transition points. This is a reflection of the non-linear nature 
15 of the processes defined in an operations methodology. The operations activity 

planning chart 902 also details the interrelationships 914 between the tasks. 
[00119] Preferably, embedded in the area of each box representing the tasks 
is a code or link selectable to display the task document that provides a task 
planning chart and detailed information describing the activity. When the link is 
20 present, clicking on a task box in the activity planning chart opens a task 

document. In some embodiments, due to a paucity of detail for separate tasks, the 
task details may also be described in the activity document, or hypertext links 
provided to the task description. 

[00120] Other information may also be included in the operations activity 
25 document 900. Objectives 920 provided list of the principle objectives and 

outcomes for the activity. The inputs and outputs of the activity, which may be 
deliverables or composites, may also be included. Primary inputs 922 provide a 
list of the most important inputs to the activity. Optionally, a list of secondary 
inputs may also be provided. Similarly, primary deliverables 924 information may 
30 be provided, as may secondary deliverable information. Responsible and 

participating role information 928 and 930 may also be displayed for the activity. 
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Information regarding the activity's relationships with other activities 932 may be 
provided. Optionally, Planning Considerations 932 may be displayed. Staffing, 
managing and standards considerations (not shown) may also be incorporated into 
the document 900. 

5 [00121] Finally, the activity document 900 may include links to 

supplemental information. In one embodiment, the supplemental information 
section may provide links to job aids and reference materials. Optionally, links to 
extemal resources may also be provided. 

[00122] Clicking on any of the tasks 904 through 914 on the activity 
10 planning chart 902 opens a task document, the lowest process level document in 

the methodology. An exemplary task document 1000 is shown in FIG. 10. For 
example, by clicking on the task box 904 labeled "Manage Unit Operations'' the 
corresponding task document 1000 is displayed within the active browser window 
908. Within the task document 1000, a task planning chart 1002 is provided. As 
15 described above, the task planning chart 902 contains a plurality of process steps 

depicted as boxes 1004 through 1014. Unlike the top level planning chart and the 
activity planning chart at the first and second levels of the fi-amework hierarchy, 
the boxes depicting the steps are not linked to lower level documents. Rather, the 
details of each step are described at the bottom of the document under the title 
20 "Process Steps" 1018. The individual descriptions of the steps can be viewed by 

clicking the expand icon 1032 by each step label. 

[00123] Other information may also be included in the task document 1 000. 
Objectives 1020 provide a list of the principle objectives and outcomes for the 
task. The inputs and outputs of the task, which may be deliverables or composites, 

25 may also be included. Primary inputs 1022 provide a list of the most important 

inputs to the activity. Optionally, a list of secondary inputs may also be provided. 
Similarly, primary 1024 and secondary 1026 deliverable information may be 
provided. Responsible role information 1028 may also be displayed for the 
activity. Optionally, participating role information may also be provided in the 

30 task document 1000. Optionally, key considerations 1034 for the task may be 

displayed. 
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[00124] Finally, the activity document 1000 may include links to 
supplemental information. In one embodiment, these are a titled "See Also" 
section 1036, which may provide links to job aids 1038 or checklists and external 
resources may also be provided. Links to other types of external resources 1040 
may also be incorporated into the task document. 

[00125] While the invention has been described in conjunction with specific 
embodiments it is to be understood that many alternatives, modifications, and 
variations will be apparent to those skilled in the art in light of the foregoing 
detailed description. For example, while the embodiments discussed in this 
application relate to two types of methodologies: development methodologies and 
operations methodologies, the invention may be readily applicable to other types 
of methodologies. It is therefore intended that the foregoing description be 
regarded as illustrative rather than limiting, and that it be understood that it is the 
following claims, including all equivalents, that are intended to define the spirit 
and scope of this invention. 



